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Description 

Background Of the Invention 

[0001 ] Th is inventio n relates tolinkandmedia access 
layer transaction initiation procedures in a communica- 
tion system, and more particularly to such procedures 
in time slotted communication systems. 
[0002] Link layer recovery protocols are used for error 
and loss recovery in data communication systems. Link 
layer recovery is especially crucial for wireless commu- 
nications due to the particularly harsh loss and error 
characteristics of the link. 

[0003] For cellular circuit data systems (e.g. IS-130), 
supervisory frames are typically exchanged between 
the Radio Link Protocol (RLP) peer entities for connec- 
tion establishment and for disconnection. The receiver 
RLP is not provided with advance knowledge of the du- 
ration of the connection or the last valid sequence 
number. The Mobile Data Link Protocol (MDLP) opera- 
tion in cellular digital packet data (CDPD) is similar, and 
the protocol state is maintained across periods of inac- 
tivity. 

[0004] Packet data transactions tend to be bursty with 
possibly long periods of inactivity between transactions. 
For mobile stations involved in intermittent transactions, 
with long inter-transaction times (even though each 
transaction may involve significant data transfer), main- 
taining RLP state information across long idle periods is 
a very inefficient use of network resources. Further- 
more, the exchange of supervisory frames for a discon- 
nect uses valuable air interface resources, and may re- 
sult in some additional delay for establishing new con- 
nections. Therefore, a procedure enabling quick effi- 
cient and graceful ending of transactions is desirable, 
especially when the link layer protocol is not situated 
back in the network. The GSM General Packet Radio 
Service (GPRS) uses a different approach. In the case 
of GPRS, bits are reserved in every Radio Link Control 
(RLC) block in order to indicate the end of a temporary 
block flow. This additional overhead in every RLC block 
is inefficient for long transactions, and leads to some 
loss in achievable throughput. The present invention is 
directed to overcoming, or at least reducing, the effects 
of one or more of the problems set forth above. The 
reader is referred to US-A-5 701 298. 
[0005] According to one aspect of the present inven- 
tion, there is provided a method of implementing a radio 
link protocol completion process as defined in claim 1 . 
The data blocks can be new data blocks. The data 
blocks can be retransmitted data blocks. The method 
can further include the step of committing the media ac- 
cess control layer controller to the end of the media ac- 
cess control layer transaction. The method can further 
include the step of terminating the media access control 
layer transaction when the transaction size field has a 
value equal to zero. The transaction size field values of 
1 , 2 through 2 N -2 can indicate that the media access 



2 

control layer transaction has a number of data blocks 
equal to the value of the transaction size field value. The 
method can further include the step of transmitting the 
END control block by the media access control layer 

s controller when the number of data blocks in a transmit 
buffer is less than the value of the system broadcast pa- 
rameter. The method can also further include the step 
of providing a last value sequence number for the media 
access control layer transaction within the END control 

10 block, and it can also further include the step of recov- 
ering all of a plurality of data sequence numbers up to 
and including the last valid sequence number. The 
method can further include the step of providing a last 
valid sequence numberforthe media access control lay- 

15 er transaction within the END control block. It can also 
further include the step of initiating another transaction 
when new data blocks are received at the transmit buff- 
er. The BEGI N protocol data unit can contain a proposed 
mode of operation for the media access control layer 

20 transaction. The mode of operation can be fixed coding. 
The END control block can be transmitted with other da- 
ta blocks as part of the CONTINUE protocol data unit. 
The END control blocks can have the same size as the 
fixed coding mode data blocks. The data blocks can 

25 start with an escape sequence as specified in RFC 
1662. The END block can be identified by at least one 
of a plurality of parity and control headers. The method 
can further include the step of acknowledging the END 
control block using an END block received indicator. The 

30 indicator can be located in an ARQ status protocol data 
unit. The method can further include the step of sched- 
uling the END control block for retransmission. The 
mode of operation can be incremental redundancy 
mode. The END block can be identified by at least one 

35 of a plurality of parity and control headers. The END con- 
trol block can be transmitted along with other data or 
parity blocks as part of the CONTINUE protocol data 
unit. The method can further include the step of ac- 
knowledging the END control block using an END block 

to received indicator. The indicator can be located in an 
ARQ status protocol data unit. The method can further 
include the step of scheduling the END control block for 
retransmission. 

[0006] According to another aspect of the invention 
45 there is provided a transaction oriented packet data 
communication system as defined in claim 25. The data 
blocks can be new data blocks. They can be retransmit- 
ted data blocks. The transmission controller can commit 
to the end of the media access control layer transaction. 
so The transmission controller can terminate the media ac- 
cess control layer transaction when the transaction size 
field has a value equal to zero. The transaction size field 
values of 1 ,2 through 2 N -2 can indicate that the media 
access control layer transaction has a number of data 
ss blocks equal to the value of the transaction size field 
value. The system can further include an END control 
block which can be transmitted by the media access 
control layer controller when the number of data blocks 
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in a transmit buffer is less than the value of the system 
broadcast parameter. The system can also further in- 
clude a last valid sequence number for the media ac- 
cess control layer transaction within the END control 
block, and/or it can further include a receiver for recov- s 
ering all of a plurality of data sequence numbers up to 
and including the last valid sequence number. The sys- 
tem can further include a last valid sequence number 
for the media access control layer transaction within the 
END control block, and/or it can can further include the 10 
step of initiating another transaction when new data 
blocks are received at the transmit buffer. The BEGIN 
protocol data unit can contain a proposed mode of op- 
eration for the media access control layer transaction. 
The mode of operation can be fixed coding. The END is 
control block can be transmitted with other data blocks 
as part of the CONTINUE protocol data unit. The END 
control blocks can have the same size as the fixed cod- 
ing mode data blocks, and/or the blocks can start with 
an escape sequence as specified in RFC 1662. The 20 
mode of operation can be incremental redundancy 
mode. The END block can be identified by at least one 
of a plurality of parity and control headers. The END con- 
trol block can be transmitted along with other data or 
parity blocks as part of the CONTINUE protocol data 25 
unit. The system can further include the step of acknowl- 
edging the END control block using an END block re- 
ceived indicator. The indicator can be located in an ARQ 
status protocol data unit. The system can further include 
the step of scheduling the END control block for retrans- 30 
mission. 

[0007] These and other features and advantages of 
the present invention will become apparent from the fol- 
lowing detailed description of an example of the inven- 
tion with reference to the accompanying drawings. 

Brief Description Of The Drawings 

[0008] 

Fig. 1 shows a block diagram of a communication 
system illustrating the operation on a packet data 
channel embodying the invention; 

Fig. 2 is a graph showing the probability of two or 45 
more active users having the same partial echo; 

Fig. 3 is a block diagram illustrating an examplary 
implementation of a Media Access Control (MAC) 
layer from the Layer 2 block in Fig. 1 ; so 

Fig. 4 is a block diagram describing the internal 
structure of a mobile station MAC transmission con- 
troller block shown in Fig. 3; 

55 

Fig. 5 is a state diagram describing a router process 
for the mobile station transmission controller de- 
scribed in Fig. 4; 



Fig. 6 is a state diagram describing a transmit con- 
troller process of the mobile station transmission 
controller described in Fig. 4; 

Fig. 7 is a state diagram describing another part of 
the transmit controller process of the mobile station 
transmission controller described in Fig. 4; 

Fig. B is a state diagram describing another part of 
the transmit controller process of the mobile station 
transmission controller described in Fig. 4; 

Fig. 9 is a state diagram describing another part of 
the transmit controller process of the mobile station 
transmission controller described in Fig. 4; 

Fig. 10 is a state diagram describing a retrieve re- 
transmit data blocks process performed by the 
transmit controller (TCTX) block of Fig. 4; 

Fig. 1 1 is a state diagram illustrating a retrieve new 
data blocks process performed by the transmit con- 
troller (TCTX) block of Fig. 4; 

Fig. 12 describes a construct Protocol Data Unit 
(PDU) process, a transmit (TxT) table, and a sub- 
channel controllers transmit (SCCxT) table used by 
the TCTX block of Fig. 4; 

Fig. 13 illustrates a physical control field (PCF) 
process that is executed by the mobile station trans- 
mission controller described in Fig. 4; 

Fig. 14 illustrates an automatic retransmission re- 
quest (ARQ) status process that is executed by the 
mobile station transmission controller described in 
Fig. 4; 



Fig. 16 is a state diagram illustrating a mobile sta- 
tion receive controller process preformed by the re- 
ceiver controller block of Fig. 4 while a fixed coding 
mode ARQ transaction is in progress; 

Fig. 17 is a state diagram illustrating an update re- 
ceive (Rx) state executed by the receive controller 
block of Fig. 4 when a data block is received; 

Fig. 18 is a state diagram illustrating a mobile sta- 
tion receive table, an initialize receive controller 
(TCRX) parameters process, and a BEGIN PDU 
process which are executed by the receive control- 
ler of Fig. 4; 



Fig. 15 is a state diagram illustrating a mobile sta- 
40 tion receive controller process performed by the re- 
ceiver controller block of Fig. 4 in the context of 
transaction initiation; 
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Fig. 19 is a state diagram illustrating a mobile sta- 
tion channel access manager (CAM) block of Fig. 3; 

Fig. 20 is a state diagram illustrating the choose 
transmit controller (TCy) process and send coded 
MAC_PDU process which are executed by the CAM 
block of Fig. 3; 

Fig. 21 is a state diagram illustrating a mobile sta- 
tion sub-channel controller process (SCC) block of 



Fig. 22 is a state diagram illustrating a check desti- 
nation and extract coded MAC_PDU process that 
is executed by the SCC block of Fig. 3 on obtaining 
data from the physical layer of Fig. 3; 

Fig. 23 shows a signal flow diagram for an END pro- 
cedure for a bounded transaction; and 

Fig. 24 is a signal flow diagram of an END Proce- 
dure for Unbounded Transaction. 

Detailed Description 

[0009] The embodiment described uses the media 
access control (MAC) layer assumptions which are 
based on the Open System Interconnections (OSI) 
model. OSI is an internationally accepted frame work of 
standards for communication between different sys- 
tems made by different vendors. Most of the dominant 
communication protocols used today have a structure 
based on the OSI model. The OSI model organizes the 
communication process into seven different categories 
and places these categories in layered sequence based 
on their relation to the user. Layer 7 through 4 deal with 
the end to end communication message source and the 
message destination. While Layers 3 through 1 deal 
with network access. 

[001 0] Layer 1 , the physical layer, deals with the phys- 
ical means of sending data over lines i.e. the electrical, 
mechanical and functional control of data circuits. Layer 
2, the data link layer, deals with procedures and proto- 
cols for operating communication lines. Layer3, the net- 
work layer, determines how data is transferred between 
computers and routing within and between individual 
networks. 

[001 1 ] It is appreciated that the packet data channel 
is capable of supporting multiple modulations. The MAC 
layer is provided with frames of Layer 3 and translates 
them into a byte stream using flag delimiters. A radio 
link protocol (RLP), also referred to as a retransmission 
link protocol, is used to transfer frames of Layer 2 be- 
tween a cell and the mobile station and vice versa. The 
byte stream of Layer 3 is segmented into RLP frames, 
and a sliding window retransmission scheme is used for 
in-sequence delivery and recovery. 
[0012] MAC layer transaction preferably starts with 



the transmission of a BEGIN frame. On the uplink and 
downlink, the MAC layer converts the frames of Layer 
3 into a byte stream and packs the byte stream into a 
series of CONTINUE frames. The last new data burst of 

s a transaction is transmitted using an END frame. 
[0013] The BEGIN frame of each transaction is trans- 
mitted using 4-level modulation in a stop and wait mode 
to obtain an acknowledgment from the receiver. On re- 
ception of the BEGIN frame, the receiver initializes an 

10 RLP. The BEGIN frame is also used to initialize a partial 
echo (PE) for the transaction, and to specify the mode 
of operation for subsequent automatic retransmission 
request (ARQ) mode CONTINUE frames in that trans- 
action. 

'5 [0014] There are two possible modes of operation for 
ARQ mode CONTINUE frames on the downlink and up- 
link. The first is incremental redundancy (mode 0) and 
the second is fixed coding (mode 1). It is appreciated 
that both mode 0 and mode 1 operate with either fixed 

20 modulation or adaptive modulation. 

[0015] ARQ checks for errors in transmitted data. The 
sender encodes an error-detection (check) field in the 
transmitted data based on the contents of the message. 
The receiver then recalculates the check field and com- 

25 pares it with the check field received. If the check fields 
match, an ACK (acknowledgment) is transmitted to the 
sender. If both check fields do not match, a NAK (neg- 
ative acknowledgment) is returned, and the sender re- 
transmits the message. 

30 [0016] For both uplink and downlink transmissions, 
bitmap feedback in the form of an ARQ status is provid- 
ed. In addition, ACK/NAK feedback is provided on a per 
time slot basis for uplink transmissions. 
[0017] Fig. I shows a high level block diagram of op- 

35 eration on the packet data channel 100 in accordance 
with the invention A transaction oriented packet data 
communication system 105 is shown where Layer 3 
frames 1 1 0 are provided to the Layer 2, MAC Layer 115, 
at the transmitter 120 and are translated into a byte 

40 stream using flags for demarcation. This permits the 
MAC layer 115 to provide a unified transport mechanism 
for different Layer 3 protocols. This byte stream is seg- 
mented into RLP frames and assigned a frame se- 
quence number (FSN). The FSN is not explicitly trans- 

« mitted as part of the RLP frame. 

[0018] For higher throughput in either mode, Layer 1 
1 25 data is mapped into symbols chosen from a 4-level, 
8-level or 1 6-level modulation based on knowledge of 
Layer2 backlog and channel quality feedback 1 30 from 

so the receiver 135. The channel quality is measuredjn 

terms of the signal to interference plus noise ratio, 

at the input to the decoder in the Layer 2 block 1 4rj via 
physical layer 1 45 at the receiver 1 35. The decoder 1 40 
then outputs the Layer 3 frames 150. 

55 [0019] The IS-136 Digital Control Channel uses a 
temporary mobile station identifier also called a Partial 
Echo (PE). The PE is assumed to be an abbreviated 
Mobile Station Identity (MSID), i.e., the last 7 bits of the 
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MSIDis treated as the PE. Due to this mechanism, there 
is a significant probability that two or more active users 
would use the same PE, and that erroneous protocol 
states would result frequently due to inability of mobiles 
to resolve their PE's correctly. 

[0020] In Fig. 2, this probability is shown as a function 
of the number users that are simultaneously active on 
the channel. In packet data applications (as opposed to 
voice or circuit data applications), it is quite possible to 
have ten or more active users at any given time sharing 
the same channel. In these cases, the probability of par- 
tial echo duplication reaches 25% and higher which is 
unacceptable for proper system operation. 
[0021] The problem is selectively solved by assigning 
a PE value (such as a dynamic PE) or an active mobile 
identity (AMI) to every mobile for all downlink transac- 
tions, and for uplink transactions which require more 
than a single burst. The AMI serves as a unique (as- 
signed) local identifier to be used by the transmitter and 
the receiver for the duration of the transaction on a par- 
ticular packet data channel. A new AMI is assigned for 
each new transaction thus eliminating the potential for 
ambiguity. The same AMI may be used in either direc- 
tion (i.e., the AMI assignment is initiated by the uplink 
or downlink transaction, whichever begins first, and re- 
mains assigned till the end of data transfer in both di- 
rections). 

[0022] A new transaction is initiated when a transmis- 
sion opportunity is identified and if the transmit buffer 
contains new data. Downlink transactions may be ACK 
or NAK but uplink transactions are always ACK. Prefer- 
ably every MAC layer transaction starts with a BEGIN 
Protocol Data Unit (PDU) handshake and proceeds with 
the transmission of a series of CONTINUE PDUs. ARQ 
mode CONTINUE PDUs may be transmitted in Incre- 
mental redundancy Mode (mode 0) or Fixed coding 
Mode (mode 1 ), and ARQ procedures forthe two modes 
are different. Supervisory ARQ Status PDUs are used 
to provide the transmitter with periodic feedback of the 
receiver state. 

[0023] The BEGIN PDU handshake (i.e., ACK trans- 
fer of the BEGIN PDU) establishes the AMI and the 
mode of operation for subsequent CONTINUE PDUs. It 
is appreciated that on multi-rate channels, it may also 
selectively be used to carry out phase assignment. 
[0024] Base stations (also know as cells) selectively 
initiate downlink transactions through the transmission 
of a BEGIN PDU. The parameters indicated by the BE- 
GIN PDU include: a Mobile Station Identity (MSID); an 
ARQ Mode (AM) indicating whether the transaction is 
ACK or NAK; a Poll Indicator (PI) for ACK transactions 
indicating whether the mobile station is required to pro- 
vide an ACK via an ARQ Status PDU; an AMI value to 
be assigned to the mobile station; a Mode Indicator (Ml) 
indicating whether the mode of operation for subse- 
quent downlink CONTINUE PDUs is Fixed Coding or 
Incremental Redundancy and a Phase Assignment (PA) 
indicating the phase for the transfer of subsequent data 



on the uplink or downlink. 

[0025] If an AMI has already been assigned to the mo- 
bile station, the base station assigns the same AMI val- 
ue within the BEGIN PDU. If the mobile station does not 

s have a valid AMI, the base station randomly chooses an 
AMI value from the set of allowable values and assigns 
it to the mobile station using the BEGIN PDU. The base 
station Transmit Controller initializes a RLP in the indi- 
cated mode (IR or FC) on transmission of the BEGIN 

10 PDU. The mobile station Receive Controller initializes a 
peer RLP in the assigned mode on receipt of the BEGIN 
PDU. 

[0026] Fig. 3 illustrates an example implementation of 
the Media Access Control (MAC) 155 Layer in a duplex 

is wireless data communication system. The MAC 1 55 in- 
terfaces with Layer 3 1 60 (network layer), physical layer 
(Layer 1) 165 (which includes a MAC layer transmitter 
1 66 and MAC layer receiver 1 67) and with the manage- 
ment entity 170. In this example, the MAC 155 provides 

20 data and expedited control delivery services to Layer 3 
160 and other higher layer entities. The MAC 155 uses 
Layer I 1 65, via the MAC layer transmitter 1 66, for de- 
livery of its PDUs over a radio interface 175. The man- 
agement entity 170 initializes, terminates, suspends, 

2s resumes and configures MAC 155 operation. The man- 
agement entity 170 also monitors the MAC 155 for er- 
rors. The management entity 1 70 also provides dynamic 
PE management fo the transaction packet data commu- 
nication system 1 05, Fig. 1 . The MAC 155 includes two 

30 Service Access Points (SAPs): SAP1 for regular data 
and SAP0 for expedited data and control. Each SAP has 
a corresponding transmit buffer (TXB), segmenter 
(SGM), desegmenter (DSGM), frame extractor (FRX) 
and transmission controller (TC). A channel access 

35 manager (CAM) 1 80 multiplexes the PDUs from the dif- 
ferent transmission controllers (also known as ARQ en- 
gine) TC0 and TC1 , Fig. 3, and provides priority sched- 
uling. The CAM 180 is also responsible for uplink ran- 
dom access. A MAC subchannel controllers (SCC) 1 85, 

40 preferably up to 9 (SCC0 through SCC8), control trans- 
mission over each of the wireless data subchannels. 
The MAC Layer Controller (MLC) 1 90 controls overall 
MAC configuration and interfaces with management en- 
tity 170. PDU encoders (PENC0 and PENC1) and de- 

45 coders (PDEC0 and PDEC1) provide channel coding/ 
decoding forthe MAC PDUs in mode 0 (incremental re- 
dundancy) or mode 1 (fixed coding). A mode 0 segment 
encoder (SENC0) and decoder (SDEC0) provide cod- 
ing/decoding, interleaving/deinterleaving and blocking/ 

so deblocking in incremental redundancy mode of trans- 
mission, 

[0027] Fig. 4 shows internal structure of a mobile sta- 
tion's MAC transmission controller (TC) from Fig 3 and 
located within the MAC layer 2 1 1 5) Fig. 1 , of the trans- 
55 mitter 120. The transmission controller 1 92 consists of 
the following sub-blocks: a transmit controller (TCTX) 
1 95, receive controller (TCRX) 200, broadcast controller 
(TCB) 205 and router (TCRT) 21 0. The transmit control- 
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ler 195 is connected to the segmenter (SGMO and 
SGM1, Fig. 3), PDU encoder (PENCO and PENC1), 
CAM 1 80, MLC 1 90 and TCRT 21 0, Fig. 4. The TCRX 
200 and TCB 205 controllers are connected to deseg- 
menter (DSGM, Fig. 3), MLC 190 and TCRT 210, Fig. 

4. The TCRT21 0 is connected to TCTX 1 95, TCRX 200, 
TCB 205, MLC 190, Fig. 3, and PDU decoder (PDEC0 
or PDEC1). 

[0028] Fig. 5 is a state diagram that describes a router 
process for the mobile station transmission controller 
1 92 of Fig. 4. The router 21 0, Fig. 4, preferably transfers 
decoded frames to an appropriate process (transmit, re- 
ceive or broadcast controllers) within the transmission 
controller 192. The router 210 is also preferably em- 
ployed to receive control information, such as phase as- 
signment, poll indication, broadcast change notification 
and page continuation indication that may selectively be 
transmitted to the mobile by a peer transmission con- 
troller located at a base station. The router 210 tracks 
whether the mobile station is in the sleep state 215, Fig 

5, or awake state 220 and whether the AMI has been 
assigned to the mobile. It is appreciated that depending 
on the conditions, the router 210, Fig. 4, routes received 
frames accordingly. 

[0029] The router 21 0 receives decoded frames from 
the CAM 1 80, Fig. 3, via a data.ind() primitive. The router 
210, Fig. 4, may be moved by the MLC 190, Fig. 3, from 
the sleep 215, Fig. 5, to awake 220 states and back via 
wake.req() and sleep. req() primitives respectively. The 
router21 0, Fig. 4, issues data.ind() primitives to receive, 
transmit or broadcast controllers (TCRX 200, TCTX 1 95 
and TCB 205) of Fig. 4. The router 21 0 informs the MLC 
1 90, Fig. 3, about a page or page continuation reception 
(via wake.ind()), broadcast change notification recep- 
tion (via bcn.indQ) and new phase assignment (via 
phase. ind()/phase.req()). 

[0030] Fig. 6 illustrates the idle state interaction of the 
transmit controller 192, Fig. 4, with the CAM 180, Fig. 

3, and a PDU encoder (PENCO or PENC1). As seen in 
Fig. 6 also illustrates an example of a transition to the 
wait for assignment state. 

[0031] In Fig. 6 a retrieve block for transmission in a 
BEGIN PDU process which is preferably executed in the 
beginning of the uplinktransaction so as to retrieve data 
from the segmenter (SGMO or SGM1 Fig. 3) and to de- 
termine whether the end of transaction process should 
be executed based on the transaction size. 
[0032] The transmit controller 192, Fig. 4, receives 
poll.indO primitives from the CAM 180, Fig. 3, when a 
transmission opportunity on the uplink occurs. The 
transmit controller 192, Fig. 4, responds with the poll. 
res() primitive indicating whether the process may se- 
lectively send data. In the idle state, the TCTX 1 95, Fig. 

4, sends BEGIN or ARQ STATUS PDUs. If the CAM 1 80, 
Fig. 3, provides a transmission opportunity to this TCTX 
1 95, Fig. 4, the TCTX 1 95 responds with poll.con() prim- 
itive. The TCTX 1 95 constructs a PDU and passes the 
PDU to a PDU encoder via data.reqQ and, in case of 



10 

BEGIN PDU , enters the wait for assignment state. When 
retrieving data for BEGIN PDU, the TCTX 192 counts 
the number of data blocks in a buffer (TXB0 or TXB1, 
Fig. 3) and determines if it it should commit to the end 

s of the transaction (NB.Tx<NB.Max and End.Tx.Flag = 
True) from the start or if the transaction should start as 
unbounded (NB.Tx=NB. Max and End.Tx.Flag = False). 
IftheTCTX 195, Fig. 4commits to the endof transaction 
from the start the TS (Transaction Size) field in the BE- 

io GIN PDU is set to the size of the transaction in data 
blocks, otherwise it is set to NB.Max (maximum value 
of NB.max is 63). As an example of the data block for- 
mat, the data block start with an escape sequence as 
specified in RFC 1662 which is described in IETF RFC 

15 1662; "PPP in HDLC-Like Framing," July 1994. 

[0033] Fig. 7 shows the wait for assignment state in- 
teraction, described in Fig. 6 of the transmit controller 
192, Fig. 4, with the CAM 180. Fig. 3, and PENC1. Fig. 
7 also describes both a count new data blocks process 

20 and a retrieve ARQ status bitmap process. The count 
new data block process is preferably executed every 
time the TCTX 1 95, Fig. 4, has to determine the amount 
of data in the MAC buffer, Fig. 3, that has preferably nev- 
er been sent over the air but still may selectively be in- 

25 eluded in the current transaction. The retrieve ARQ sta- 
tus bitmap process involves communicating with the re- 
ceive controller (TCRX 200, Fig. 4, to retrieve a bitmap 
indicating the state of the ARQ protocol for the downlink 
transaction. 

30 [0034] The transmit controller 1 92 receives poll.ind() 
primitives from the CAM 180, Fig. 3, when a transmis- 
sion opportunity on the uplink occurs. The transmit con- 
troller 192, Fig. 4, responds with the poll.res() primitive 
indicating that the transmit controller 1 92 may selective- 

35 ly send data. In the wait for assignment state, the TCTX 
1 95 may selectively send ARQ STATUS PDUs (if polled 
for it by peer transmission controller 192). If CAM 180, 
Fig. 3, provides a transmission opportunity to this TCTX 
195, Fig. 4, the CAM 180, Fig.3,sendsapoll.con()prim- 

40 itive. The TCTX 195, Fig. 4, retrieves ARQ status bit- 
map, constructs a PDU , and passes the PDU to the PDU 
encoder via a data.req(). When counting new data 
blocks, the TCTX 1 95, Fig. 4, first checks if it has already 
committed to the end of current transaction 

45 (End_Tx_Flag = True) . If this is the case, the TCTX 1 95 
counts only the blocks remaining until the end of current 
transaction (indicated by BST_Status) and ignores data 
that might have arrived to the buffer (TXB0 orTXBI , Fig. 
3) after transaction end had been committed to. If not, 

so the TCTX 195, Fig. 4, counts all data in MAC buffers, 
TXB0 or TXB1, Fig. 3, (indicated by the sum of 
BST_Status and TXB_Status). If the number of new 
blocks counted in such a way is larger than NB_Max, 
the transaction may selectively continue as unbounded. 

55 Otherwise the end procedure is required. 

[0035] Fig. 8 illustrates transitions between the idle, 
waitfor assignment and transaction in progress in mode 
0 and mode 1 states. The TCTX 1 95, Fig. 4, may selec- 
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tively transition from the wait for sssignment state to one 
of the transaction in progress states (depending on up- 
link mode (UL_Mode) negotiated with the base station) 
after receiving positive acknowledgment to its BEGIN 
PDU via a PCF (as indicated by data.con() primitive from 
the CAM and Error=Null condition being True) or after 
receiving the downlink ARQ status PDU with AMI as- 
signment (as indicated by data.ind(ARQ_Status_Rx) 
primitive from TCRT 200 and conditions of WAI and 
AMI=AMl_ldle being False). In the wait for assignment 
state timers T_WA and T_BOFF_START may selective- 
ly expire and the TCTX 195 may selectively transition 
back to the idle states. These timers designate the 
amount of time the mobile station should wait for the 
AM I/Mode assignment via ARQ Status PDU before the 
mobile station is allowed to repeat its access attempt. 
[0036] In the transaction in progress (mode 0 and 
mode 1) states, the TCTX 195 may selectively receive 
acknowledgments via a PCF (data.con() from CAM 1 80, 
Fig. 3) and via ARQ Status PDU (data.ind() from TCRT 
200, Fig. 4). If the transmit table 230, Fig. 12, is empty 
and there is no new data (no data backlog) to send 
(NB_Tx<=0), the transaction is completed and the 
TCTX 1 95, Fig. 4, selectively transitions to the idle state. 
Otherwise, the TCTX 195 remains in the transaction in 
progress states, unless the inactivity timer (TJNAC) ex- 
pires. 

[0037] Fig. 9 describes the transaction in progress 
state, describe in Fig. 8, interaction of the transmit con- 
troller 1 92, Fig. 4, with the CAM 1 80, Fig. 3, and the PDU 
encoder (PENC0 or PENC1 , Fig. 3). Fig. 9 also de- 
scribes the find retransmit data blocks process. This 
process is executed selectively every time the TCTX 
195, Fig. 4, determines if there are any data blocks in 
the transmit table 230, Fig. 12, that have not been ac- 
knowledged by the receiver and are retransmitable i.e. 
there is a data backlog. 

[0038] The transmit controller 1 92 receives a poll.ind 
() primitives from the CAM 180, Fig. 3, when a transmis- 
sion opportunity on the uplink occurs. The transmit con- 
troller 192 responds with the poll.res() primitive indicat- 
ing whether it can or must send data. In the transaction 
in progress state the TCTX 1 95, Fig. 4, may selectively 
send ARQ STATUS (if polled for it by peer transmission 
controller) or CONTINUE PDUs. If the CAM 180, Fig. 3, 
decides to provide a transmission opportunity to this 
TCTX 195, Fig. 4, the CAM 180, Fig. 3, sends a poll.con 
() primitive. The TCTX 195, Fig. 4, constructs a PDU, 
and passes it to the PDU encoder via data.req(). 
[0039] Fig. 10 describes a retrieve retransmit data 
blocks process. The process is executed by the TCTX 
1 95, Fig. 4, every time TCTX 1 95 constructs the CON- 
TINUE PDU which includes data blocks that have been 
transmitted previously but must be retransmitted again 
because the receiver failed to decode them properly (i. 
e. another type of data backlog) The number of such 
data blocks depends upon the current modulation (as 
examples 3 blocks for 8-level modulation and 2 blocks 



for 4 level) and on whether the previously transmitted 
End block has to be retransmitted to inform the receiver 
about the last sequence number it should expect for the 
transaction. If the End block has to be retransmitted 

s (End_RTx_Flag = False), the process generates the 
End block and places it in the SCCxT table 235, Fig. 12. 
If after retrieving the retransmit data blocks there is still 
a space remaining in the PDU, the process fills this 
space with either the redundant End block (if the end 

10 procedure is in progress, i.e. End_Tx_Flag=True) or 
with the filler block (if the end procedure has not yet been 
started, i.e. End_Tx_Flag=False). 
[0040] Fig. 11 illustrates a retrieve new data blocks 
process. This process is executed bytheTCTX 1 95, Fig, 

» 4, every time the TCTX 1 95 constructs the CONTI N U E 
PDU which includes data blocks that has never been 
transmitted previously (another type of data backlog). 
The number of such data blocks depends upon the cur- 
rent modulation (as examples 3 blocks for 8-level mod- 

20 ulation, 2 blocks for 4 level) and on whether the End 
block has to be transmitted to inform the receiver about 
the last sequence number it should expect for the trans- 
action. If the previously transmitted End block has to be 
retransmitted again (End_RTx_Flag = False) or if the 

25 number of new data blocks in MAC buffers (TXB0 and 
TXB1, Fig. 3) is smaller than a predefined threshold 
(NB_Tx<NB_Max), the process generates the End 
block and places it in the SCCxT table 235, Fig, 12. If 
after retrieving new data blocks there is still a space re- 

30 maining in the PDU, the process fills this space up with 
either the redundant End block (if the end procedure is 
in progress, i.e. End_Tx_Flag=True) or with the filler 
block (if the end procedure has not yet been started, i. 
e. End_Tx_Flag=False). 

35 [0041] Fig. 12 describes a construct PDU process 
225, a transmit (TxT) table 230, and a sub-channel con- 
trollers transmit (SCCxT) table 235 used by the TCTX 
195, Fig. 4. The construct PDU process 225 illustrates 
how various control and data fields in the PDUs are filled 

to up with values and data. The TxT table 230, Fig. 1 2, is 
used to track ARQ state of the transmit controller 192, 
Fig. 4, i.e. the status and order of the previously trans- 
mitted data blocks within the transmit window. The SC- 
CxT table 235 is used to track the association between 

45 blocks and the PDUs and the sub-channels that the 
PDUs have been transmitted on. The SCCxT table 235 
stores information on all MAC blocks in transit that have 
not yet been acknowledged via a physical control field 
(PCF). The SCCxT table 235 is also used to facilitate 

so construction of PDUs. Both the TxT 230 and SCCxT 235 
tables are means to determine a data backlog with the 
MAC layer. 

[0042] Fig. 1 3 shows a PCF process that is executed 
as part of the mobile station transmit controller 1 92, Fig. 
ss 4. The PCF provides acknowledgment for all blocks 
transmitted in the previous uplink burst on thesub-chan- 
nel. If the PCF indicates that the previous uplink trans- 
mission on the sub-channel was received, a transmit ta- 
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ble corresponding to the blocks transmitted is updated. 
The ARQ state variables at the TC 1 92 are also updated 
to reflect the PCF acknowledgment. The TC 1 92 pro- 
vides a data.con signal to the segmenter (SGMO or 
SGM1 , Fig. 3) for each block acknowledged. If the data 
blocks transmitted in the previous uplink burst on the 
subchannel are negatively acknowledged via the PCF, 
then the data blocks are marked as retransmittable. 
[0043] Fig. 14 illustrates an ARQ status process that 
is executed selectively by the mobile station transmit 
controller 1 92, Fig. 4. An ARQ Status PDU maybe used 
to assign an AMI and mode to the mobile station if the 
AMI and/or mode proposed by the mobile station are 
unacceptable. Alternatively, it may indicate that the mo- 
bile station must wait for a subsequent AM I and/or mode 
assignment. This process also causes an update of the 
ARQ state variables and transmit table (TxT 230, Fig. 
1 2) at the TC 1 92. If a NND field in the ARQ Status PDU 
is set, then the mobile station assumes that no new Lay- 
er 3 data may be transmitted. If an End block was trans- 
mitted while nearing the end of the transaction, then the 
End block is acknowledged through an EBR bit in the 
ARQ Status PDU. If the ARQ status PDU includes a pri- 
mary bitmap indicating the receipt status of all blocks 
within the receive window, then this bitmap is used to 
update the receipt and retransmittability status of blocks 
within the transmit table (i.e., the transmit controller un- 
derstands the receive window). For each block acknowl- 
edged by the bitmap, the TC 1 92 provides a data.con 
signal to the segmenter. 

[0044] Fig. 1 5 shows the mobile station receive con- 
troller process in the context of transaction initiation. Fig. 
15 illustrates signals obtained by the receive controller 
(TCRX) 200, Fig. 4, from the PDU decoder, PDEC0 or 
PDEC1, Fig. 3 (in state Data.ind). Also shown are sig- 
nals sent by the TCRX 200, Fig. 4, process to a deseg- 
menter, DSGM0 or DSGM 1 , Fig. 3 (in state Data.ind ) 
and MLC 190 in state StartRx.ind. 
[0045] BEGIN PDUs are selectively received while 
the TCRX 200, Fig. 4, is in the idle state. On receiving 
a BEGIN PDU from the PDU decoder, PDEC0 or 
PDEC1 , Fig. 3, theTCRX 200, Fig. 4 determines wheth- 
er the transaction is acknowledged and whether the 
transaction is bounded (i.e., limited to the transfer of 
NB_Rx Data blocks). For ARQ transactions, the TCRX 
200 also determines the ARQ mode (mode 0 or mode 
1 ) for the transaction and initializes an ARQ engine (also 
known as a TC 1 92, Fig. 4) in the indicated mode. The 
TCRX 200, Fig. 3, is an example means for initiating a 
MAC transaction in response to a BEGIN frame 
[0046] Fig. 16 illustrates the mobile station receive 
controller process while a fixed coding mode ARQ trans- 
action is in progress. Fig. 16 shows signals received by 
the TCRX 200, Fig. 4, from the TCTX 1 95 (in state Poll, 
ind), MLC 190, Fig. 3, (in state StopRx.Req) and the 
PDU Decoder, PDEC0 or PDEC1, Fig. 3 (in state Data, 
ind). Also shown in Fig. 16 are signals sent by the TCRX 
200, Fig. 4, to the TCTX 195 (the state Data.req), de- 
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segmenter, DSGM0 or DSGM 1 , Fig. 3 (in state error, 
ind ), and MLC 190, Fig. 3 (in state Error.ind). 
[0047] On being polled by a TC 1 92, Fig. 4, for ARQ 
Status, the TCRX 200 generates an ARQ status PDU 

5 (which contains a bitmap indicating the receipt status of 
all blocks in a receive window) and provides it to the TC 
192. The CONTINUE PDUs are selectively received 
while a transaction is in progress. On receiving a CON- 
TINUE PDU from the PDU decoder, the TCRX 200 ex- 

10 tracts multiple blocks from the PDU. It is appreciated 
that the number of blocks extracted depends on the 
downlink modulation. The blocks are selectively of type 
end. data or filler. End and filler blocks are identified by 
escape sequences at the start of the block. If an end 

is block is received, the TCRX 200 preferably sets the last 
valid sequence number for the transaction to the se- 
quence number indicated by the end block. For each 
data block extracted, the TCRX 200 executes a update 
receive (Rx) state process. 

20 [0048] Fig. 1 7 shows the update Rx state process ex- 
ecuted by the TCRX 200, Fig. 4, when a data block is 
received. Fig. 17 shows signals sent by the receive con- 
troller 200 to the desegmenter, DSGM0 or DSGM 1 , Fig. 
3 (in state Data.ind) and MLC 190, Fig. 3 in state Sto- 

25 pRx.ind. 

[0049] The receive controller 200, Fig. 4, selectively 
invalidates and discards the data block if it lies outside 
the window or corresponds to a block that was previous- 
ly received. If the data block remains valid, the TCRX 

30 200 updates the receipt status of the block. The receive 
controller 200 also updates the two state variables, 
NR_Rx (sequence number up to which all data blocks 
have been received in-sequence) and NL_Rx (last se- 
quence number that was received). The receive control- 

35 ler 200 then delivers all data blocks that have been re- 
ceived in-sequence to the desegmenter and deletes 
these entries from a receive table. The process stops 
when the receive table is empty and NR_Rx is equal to 
the last valid sequence number for the transaction. 

40 [0050] Fig. 1 B shows the mobile station receive table 
240, an initialize TCRX 200 parameters process 245 
and a BEGIN PDU process 250 which are executed by 
the receive controller (TCRX) 200, Fig. 4. The receive 
table 240 consists of the block sequence number, data 

is block and receipt status for each sequence number 
within the receive window. The initialize TCRX 200 pa- 
rameters process 245 carries out an initialization of the 
receive table 240 and other ARQ state variables. The 
BEGIN PDU process 250 illustrates the initialization of 

so the AMI, mode and the size for the transaction. It is ap- 
preciated that these parameters are extracted from cor- 
responding fields within the BEGIN PDU. 
[0051] Fig. 1 9 shows the mobile station CAM process 
for the CAM 1 80, Fig. 3. Fig. 1 9 shows signals received 

55 from any one of the SCCs 1 85 (data.con, pcf.ind, data, 
ind) and the MLC 190 (Open.req, Config.req, Close, 
req). Fig. 1 9 also shows the signals sent by the CAM 
180 to the transmit controller 185 (data.con), PDU de- 
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coder, PDECO or PDEC1, Fig. 3 (data.ind), and MLC 
190 (Error.ind). 

[0052] The CAM 1 80 determines the order of trans- 
mission for coded MAC PDUsfrom multiple transmit 
controllers 185 (SCCO through SCC8). The CAM 180 
polls the transmission controllers 1 85 for MAC PDUs 
when it is made aware of a transmission opportunity by 
one of the MAC sub-channel controllers 185. Based on 
the response to the CAM 180 polls, the CAM 180 polls 
one of the transmit controllers 1 85 for the data. The CAM 
1 80 selectively sends coded MAC PDUs obtained from 
one of the PDU encoders (PENC1 and PENC0) to the 
appropriate SCC 1 85 for transmission over the air inter- 
face 175 (also known as the radio interface). 
[0053] The CAM 1 80 is also responsible for executing 
a random access protocol at the mobile station. This 
function manages channel access in contention mode 
and all subsequent back-off procedures in case of the 
failure of initial access. After successful access, the 
CAM 1 80 polls the transmit controllers 1 85 and pro- 
ceeds by sending PDUs in the assigned slots indicated 
by sub-channel controllers 185. 
[0054] In the receive direction, the CAM 1 80 obtains 
MAC PDUs from the sub-channel controller 185 and 
passes them on to the PDU decoder corresponding to 
the indicated mode. 

[0055] Fig. 20 illustrates a choose transmission con- 
troller (TCy) process 255 and a send coded MAC_PDU 
process 260 which are executed by the CAM 180, Fig. 
3. Fig. 20 shows signals sent by the CAM 180totheTCs 
(TC1 I and TC2, Fig. 3, and poll.ind and poll.con, Fig. 
20) and SCCs 1 85, Fig. 3 (data.req). Fig. 20 also shows 
signals received from the TCs (TC1 , TC2, Fig. 3 and 
poll.res, Fig. 20) and the PDU encoder (PENC0 and 
PENC1 , Fig. 3 and data.req, Fig. 20). 
[0056] The CAM 1 80, Fig. 3, polls each transmit con- 
troller in order of priority when it is made aware of a 
transmission opportunity by any SCC 185. Each TC 
(TC0 and TC1 ) responds with an indication that it selec- 
tively send data, can send data or has nothing to send. 
Based on the response, the CAM 180 chooses the ap- 
propriate TC (TC0 and TC1) to poll for data. Subse- 
quently, the CAM 180 obtains a coded MAC PDU from 
the PDU encoder (PENC0 and PENC1) that the CAM 
1 80 provides to the appropriate SCC 1 85 for transmis- 
sion over the air interface 1 75. 
[0057] Fig. 21 illustrates the mobile station sub-chan- 
nel controller (SCC) process. The MAC Layer has pref- 
erably 9 sub-channel controllers 185 (SCCO through 
SCC8), Fig. 3, for a triple rate channel, 6 for a double 
rate channel and 3 for a full rate channel. Each sub- 
channel controller 185 handles a packet channel feed- 
back (PCF) operation for the sub-channel and passes 
coded MAC PDUs between the CAM 1 80 and the phys- 
ical Layer 165. 

[0058] In Fig. 21, signals are received by the SCC 
185, Fig. 3, from the physical Layer 165 (PHY_DATA. 
IND), CAM 180 (Data.req) and MLC 190 (Open.req, 
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Close.req). Additionally the signals sent by the SCC 1 85 
to the CAM 1 80 (pcf ,ind, Data.con) and the physical lay- 
er 165 (PHY_DATA.REQ) are shown. 
[0059] On obtaining data from the physical layer 1 65, 

s the SCC 1 85 checks the AMI to determine if the mobile 
station is the intended recipient. If the data is not intend- 
ed for the mobile station, it is discarded; otherwise the 
coded MAC PDU is passed on to the CAM 1 80. The SCC 
1 85 also obtains contention and reserved access oppor- 

10 tunities via the PCF and polls the CAM 1 80 for data. Any 
coded MAC PDU subsequently obtained from the CAM 
180 is then passed on to the physical layer 165. After 
the PDU is transmitted, the SCC 1 85 checks the corre- 
sponding PCF field on the sub-channel in order to de- 
is termine if the PDU was received successfully. The SCC 
185 assumes a different PCF structure depending on 
whether data was transmitted using contention or res- 
ervation. The acknowledgment status obtained via PCF 
is indicated to the CAM 180. 

20 [0060] Fig. 22 illustrates a check destination and ex- 
tract coded MAC_PDU process that is executed by the 
SCC 185, Fig. 3, process on obtaining data from the 
physical layer 1 65. The SCC 1 B5 may selectively send 
a data.ind signal to the CAM 1 80 as part of this process. 

25 On obtaining data from the physical layer 1 65, the SCC 
1 85 checks the AMI to determine if the mobile station is 
the intended recipient. If the data is not intended for the 
mobile station, it is discarded; otherwise the coded MAC 
PDU is passed on to the CAM 1 80. 

30 [0061] Fig. 23 shows a signal flow diagram for an END 
procedure for a bounded transaction between a base 
station (cell) 265 and a mobile 270. In step 275, the base 
station 265 sends a BEGIN frame indicating that the 
transaction size is 8 data blocks (i.e., transaction is 

35 bounded) and polls the mobile station 270 for ARQ Sta- 
tus. This step was shown in the state diagrams when 
the SCC 1 85, Fig. 3, receives data from the physical lay- 
er 1 65 and passes it on to the CAM 1 B0 in Figs. 21 and 
22. The CAM 180, Fig. 3, then receives data from the 

40 SCC 1 85 and the decoded data is provided to the router 
(TCRT) 210, Fig. 4 (described in the Fig. 19 state dia- 
gram). The TCRT 210, Fig. 4 receives the data from 
CAM 180, Fig. 3, extracts a poll bit (PI), sets 
ARQ_Status_polled flag = PI and passes the BEGIN 

45 PDU to the TCRX 200, Fig. 4 (described in the Fig. 15). 
The TCRX 200, Fig. 4, receives the BEGIN PDU from 
the TCRT 21 0 and sets a last valid sequence number in 
Fig. 15. 

[0062] In step 2B0, the mobile station 270 acknowl- 
50 edges receipt of the BEGIN PDU by sending an ARQ 
status PDU to the base station 265 and sets the last valid 
sequence number for the transaction to 8. This step was 
shown in the state diagrams when the SCC 1 85, Fig. 3, 
detects a transmission opportunity by reading the PCF 
55 and indicates it to CAM 1 80, Fig. 3, in Fig. 21 . The CAM 
1 80, Fig. 3, polls the TCTXs 1 95 in Figs. 1 9 and 20. The 
TCTX 195, Fig. 4, on the same step, where the Begin 
PDU is received, indicates to the CAM 180, Fig. 3, that 
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it selectively sent an ARQ status PDU in Fig. 6, 7 and 
9. The CAM 1 80, Fig. 3, polls TCTX 1 95, Fig. 4, for ARQ 
status PDU in Fig. 19. The TCTX 195, Fig. 4, polls the 
TCRX 200 for an ARQ Status bitmap in Fig. 7. The 
TCRX 200, Fig. 4, generates ARQ status and provides 
it to the TCTX 1 95 in Fig. 7. The TCTX 1 95, Fig. 4, sends 
the ARQ status PDU to PDU encoder (PENC0 or 
PENC1 , Fig. 3) in Figs. 6, 7 and 9. The PDU encoder 
(PENC0 or PENC1 , Fig. 3) encodes the PDU and sends 
the encoder PDU to the CAM 1 80. The CAM 1 80 passes 
the encoder PDU on to SCC 1 85 in Fig. 7. The SCC 1 85, 
Fig. 3, then provides data to the physical Layer 165 in 
Fig. 21. 

[0063] In step 285, the base station 265 sends a CON- 
TINUE PDU to the mobile 270 which includes the data 
blocks numbered 1 and 2. This step was shown in the 
state diagrams when the SCC 1 85, Fig. 3, receives data 
from the physical layer 1 65 and-passes it on to the CAM 
180 in Figs. 21 and 22. The CAM 180, Fig. 3, then re- 
ceives data from the SCC 1 85 and the decoded data is 
provided to the router (TCRT) 210, Fig. 4 (described in 
the Fig. 1 9 state diagram). The TCRT 21 0 receives the 
data from the CAM 180, Fig. 3 and the TCRX 200, Fig. 
4, receives the CONTINUE PDU and updates the RX 
state in Fig. 16 and 17. 

[0064] In step 290, the base station 265 sends a CON- 
TINUE PDU to the mobile 270 which includes the data 
blocks numbered 3, 4 and 5. This step was shown in the 
state diagrams when the SCC 1 85, Fig. 3, receives data 
from the physical layer 1 65 and passes it on to the CAM 
180 in Figs. 21 and 22. The CAM 180, Fig. 3, then re- 
ceives data from the SCC 1 85 and the decoded data is 
provided to the router (TCRT) 210, Fig. 4 (described in 
the Fig. 1 9 state diagram). The TCRT 21 0 receives the 
data from the CAM 1 80, Fig. 3 and the TCRX 200, Fig. 
4, receives the CONTINUE PDU and updates the RX 
state in Fig. 16 and 17. 

[0065] In step 295, the base station 265 sends a CON- 
TINUE PDU to the mobile 270 which includes the data 
blocks numbered 6, 7 and 8, and polls the mobile station 
270 for an ARQ Status. This step was shown in the state 
diagrams when the SCC 1 85, Fig. 3, receives data from 
the physical layer 1 65 and passes it on to the CAM 1 80 
in Figs. 21 and 22. The CAM 180, Fig. 3, then receives 
data from the SCC 1 85 and the decoded data is provid- 
ed to the router (TCRT) 21 0, Fig. 4 (described in the Fig. 
1 9 state diagram). The TCRT21 0 receives the data from 
CAM 180, Fig.3, extracts a poll bit (PI), sets an 
ARQ_Status_polled flag = PI and passes a CONTINUE 
PDU to TCRX 200, Fig.3, in Fig.5. The TCRX 200, Fig. 
3, receives the CONTINUE PDU and updates RX state 
in Fig. 16 and 17. 

[0066] In step 300, the mobile station 270 sends an 
ARQ status to the base station 265 that acknowledges 
the receipt of blocks 1 to 8. This step was shown in the 
state diagrams when the SCC 185, Fig. 3, detects a 
transmission opportunity by reading the PCF and indi- 
cates it to CAM 180, Fig. 3, in Fig. 21. The CAM 180, 
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Fig. 3, polls the TCTXs 195 in Figs. 19 and 20. The 
TCTX 195, Fig. 4, on the same step, where the Begin 
PDU is received, indicates to the CAM 180, Fig. 3, that 
it selectively sent an ARQ status PDU in Fig. 6, 7 and 

s 9. The CAM 1 80, Fig. 3, polls TCTX 1 95, Fig. 4, for ARQ 
status PDU in Fig. 19. The TCTX 195, Fig 4, polls the 
TCRX 200 for an ARQ Status bitmap in Fig. 7. The 
TCRX 200, Fig. 4, generates ARQ status and provides 
it to the TCTX 1 95 in Fig. 7. The TCTX 1 95, Fig. 4, sends 

10 the ARQ status PDU to PDU encoder (PENC0 or PENC 
1 , Fig. 3) in Figs. 6, 7 and 9. The PDU encoder (PENC0 
or PENC1 , Fig. 3) encodes the PDU and sends the en- 
coder PDU to the CAM 1 80. The CAM 1 80 passes the 
encoder PDU on to SCC 185 in Fig. 7. The SCC 185, 

15 Fig. 3, then provides data to the physical Layer 1 65 in 
Fig. 21. 

[0067] Fig. 24 is a signal flow diagram of an END Pro- 
cedure for Unbounded Transaction. In step 305, the 
base station 265 sends a BEGIN frame to the mobile 

20 270 indicating that the transaction is unbounded and 
polls the mobile station 270 for an ARQ Status. This step 
was shown in the state diagrams when the SCC 185, 
Fig. 3, receives data from the physical layer 1 65 and 
passes it on to the CAM 180 in Figs. 21 and 22. The 

25 CAM 1 80, Fig. 3, then receives data from the SCC 1 85 
and the decoded data is provided to the router (TCRT) 
210, Fig 4 (described in the Fig. 19 state diagram). The 
TCRT 21 0, Fig. 4 receives the data from CAM 1 80, Fig. 
3, extracts a poll bit (PI), sets ARQ_Status_polled flag 

30 = PI and passes the BEGIN PDU to the TCRX 200, Fig. 
4 (described in the Fig. 15). The TCRX 200, Fig. 4, re- 
ceives the BEGIN PDU from the TCRT 21 0 and sets a 
last valid sequence number in Fig. 1 5. 
[0068] In step 310, the mobile station 270 acknowl- 

35 edges receipt of the BEGIN PDU by sending an ARQ 
Status PDU to the base station 265. This step was 
shown in the state diagrams when the SCC 1 85, Fig. 3, 
detects a transmission opportunity by reading the PCF 
and indicates it to CAM 1 80, Fig. 3, in Fig. 21 . The CAM 

to 180, Fig.3, polls the TCTXs 195 in Figs. 19 and 20. The 
TCTX 195, Fig. 4, on the same step, where the Begin 
PDU is received, indicates to the CAM 180, Fig. 3, that 
it selectively sent an ARQ status PDU in Fig. 6, 7 and 
9. The CAM 180, Fig. 3, polls TCTX 195, Fig. 4, for ARQ 

45 status PDU in Fig. 19 The TCTX 195. Fig. 4, polls the 
TCRX 200 for an ARQ Status bitmap in Fig. 7. The 
TCRX 200, Fig. 4, generates ARQ status and provides 
it to the TCTX 1 95 in Fig. 7. The TCTX 1 95, Fig. 4, sends 
the ARQ status PDU to PDU encoder (PENC0 or 

so PENC1 , Fig. 3) in Figs. 6, 7 and 9. The PDU encoder 
(PENC0 or PENC1 , Fig. 3) encodes the PDU and sends 
the encoder PDU to the CAM 1 80. The CAM 1 80 passes 
the encoder PDU on to SCC 1 85 in Fig. 7. The SCC 1 85, 
Fig. 3, then provides data to the physical Layer 1 65 in 

55 Fig. 21 . 

[0069] In step 315, the base station 265 sends sub- 
sequent CONTINUE PDUs to the mobile 270. This step 
was shown in the state diagrams when the SCC 1 85, 
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Fig. 3, receives data from the physical layer 1 65 and 
passes it on to the CAM 180 in Figs. 21 and 22. The 
CAM 1 80, Fig. 3, then receives data from the SCC 1 85 
and the decoded data is provided to the router (TCRT) 
21 0, Fig. 4 (described in the Fig. 1 9 state diagram). The 
TCRT 210 receives the data from the CAM 180, Fig. 3 
and the TCRX 200, Fig. 4, receives the CONTINUE 
PDU and updates the RX state in Fig. 16 and 17. 
[0070] In step 320, while nearingthe end of the trans- 
action, the base station 265 includes an END block 
which indicates the last valid sequence number (set to 
1 00) forthe transaction within the CONTINUE PDU. The 
base station 265 also polls the mobile station 270 for an 
ARQ status. This step was shown in the state diagrams 
when the SCC 1 85, Fig. 3, receives data from the phys- 
ical layer 1 65 and passes it on to the CAM 1 80 in Figs. 
21 and 22. The CAM 1 80, Fig. 3, then receives data from 
the SCC 1 85 and the decoded data is provided to the 
router (TCRT) 21 0, Fig. 4 (described in the Fig. 1 9 state 
diagram). TCRT 210, Fig. 4, receives data from CAM 
180, Fig. 3, extracts a poll bit (PI), sets 
ARQ_Status_polled flag = PI and passes the CONTIN- 
UE PDU to the TCRX 200 (Fig. 4) in Fig. 5. The TCRX 
200, Fig. 4, receives the CONTINUE PDU, extracts an 
End block from the CONTINUE PDU and sets the last 
valid sequence number to that indicated by the End 
block in Fig. 1 6. For all other data blocks extracted from 
the CONTINUE PDU, theTCRX 200, Fig. 4, updates Rx 
state in Fig. 16 and 17. 

[0071] In step 325, the mobile station 270 sends an 
ARQ status tothe base station 265 which acknowledges 
the receipt of the END block through an End Block re- 
ceived (EBR) field. The ARQ status also includes a bit- 
map indicating the receipt status of other blocks within 
the receive window. This step was shown in the state 
diagrams when the SCC 1 85, Fig. 3, detects a transmis- 
sion opportunity by reading the PCF and indicates it to 
CAM 1 80, Fig. 3, in Fig. 21 . The CAM 1 80, Fig. 3, polls 
the TCTXs 1 95 in Figs. 1 9 and 20. The TCTX 1 95, Fig. 
4, on the same step, where the Begin PDU is received, 
indicates to the CAM 1 80, Fig. 3, that it selectively sent 
an ARQ status PDU in Fig. 6, 7 and 9. The CAM 180, 
Fig. 3, polls TCTX 195, Fig. 4, for ARQ status PDU in 
Fig. 19. The TCTX 195, Fig. 4, polls the TCRX 200 for 
an ARQ Status bitmap in Fig. 7. The TCRX 200, Fig. 4, 
generates ARQ status with the EBR bit set and provides 
it to the TCTX 195 in Fig. 7. The TCTX 195, Fig. 4, sends 
the ARQ status PDU to PDU encoder (PENC0 or 
PENC1, Fig. 3) in Figs. 6, 7 and 9. The PDU encoder 
(PENC0 or PENC 1 , Fig. 3) encodes the PDU and sends 
the encoder PDU to the CAM 1 80. The CAM 1 80 passes 
the encoder PDU on to SCC 1 85 in Fig. 7. The SCC 1 85, 
Fig. 3, then provides data to the physical Layer 1 65 in 
Fig. 21. 

[0072] In step 330, the base station 265 sends sub- 
sequent CONTINUE PDUs to the mobile 270. This step 
was shown in the state diagrams when the SCC 185, 
Fig. 3, receives data from the physical layer 1 65 and 



20 

passes it on to the CAM 180 in Figs. 21 and 22. The 
CAM 180, Fig. 3, then receives data from the SCC 185 
and the decoded data is provided to the router (TCRT) 
210, Fig. 4 (described in the Fig. 19 state diagram). The 
5 TCRT 21 0 receives the data from the CAM 1 80, Fig. 3 
and the TCRX 200, Fig. 4, receives the CONTINUE 
PDU and updates the RX state in Fig. 16 and 17. 
[0073] In step 335, the base station 265 sends CON- 
TINUE PDU to the mobile 270 which include blocks 99 
10 and 100, and polls the mobile 270 for an ARQ status. 
This step was shown in the state diagrams when the 
SCC 185, Fig. 3, receives data from the physical layer 
165 and passes it on to the CAM 180 in Figs. 21 and 22. 
The CAM 1 80, Fig. 3, then receives data from the SCC 
'5 185 and the decoded data is provided to the router 
(TCRT) 210, Fig. 4 (described in the Fig. 19 state dia- 
gram). The TCRT 21 0 receives the data from the CAM 
1 80, Fig. 3 and the TCRX 200, Fig. 4, receives the CON- 
TINUE PDU and updates the RX state in Fig. 1 6 and 1 7 
20 [0074] In step 340, the mobile station 270 responds 
to the mobile 265 with the ARQ status which indicates 
that all blocks up to and including the last valid sequence 
number have been received in-sequence. This step was 
shown in the state diagrams when the SCC 1 85, Fig. 3, 
25 detects a transmission opportunity by reading the PCF 
and indicates it to CAM 1 B0, Fig. 3, in Fig. 21 . The CAM 
1 80, Fig. 3, polls the TCTXs 1 95 in Figs. 1 9 and 20. The 
TCTX 1 95, Fig. 4, on the same step, where the Begin 
PDU is received, indicates to the CAM 180, Fig. 3, that 
so it selectively sent an ARQ status PDU in Fig. 6, 7 and 
9. The CAM 180, Fig. 3, polls TCTX 195, Fig. 4, for ARQ 
status PDU in Fig. 19. The TCTX 195, Fig. 4, polls the 
TCRX 200 for an ARQ Status bitmap in Fig. 7. The 
TCRX 200, Fig. 4, generates ARQ status and provides 
35 rt to the TCTX 1 95 in Fig. 7. The TCTX 1 95, Fig. 4, sends 
the ARQ status PDU to PDU encoder (PENC0 or 
PENC1 , Fig. 3) in Figs 6, 7 and 9. The PDU encode 
(PENC0 or PENC1 , Fig. 3) encodes the PDU and sends 
the encoder PDU to the CAM 1 80. The cam 1 80 passes 
40 the encoder PDU on to SCC 1 85 in Fig. 7. The SCC 1 85, 
Fig. 3, then provides data to the physical Layer 165 in 
Fig. 21. 

[0075] Broadly, the example implements a radio link 
protocol (RLP) completion process for a transaction ori- 

45 ented packet data communication system. The example 
performs the steps of determining a data backlog (in the 
buffers TXB0 and TXB1 , Fig. 3) with a media access 
control layer controller (MLC 190), and transmitting a 
BEGIN PDU containing a flag (transaction size indica- 

so tor) to a receiver 1 67. The example further includes the 
step of initiating a media access control layer transac- 
tion (at the MLC 1 90) in response to the transmitting of 
the BEGIN PDU. The data backlog is indicated to the 
media access controller by a network layer 1 60. The ex- 

55 ample further includes the steps of stopping data trans- 
mission after transmitting the BEGIN protocol data unit, 
and waiting for an acknowledgement message from the 
receiver 1 67. The acknowledgement message from the 
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receiver 1 67 is controlled by the sub-channel controllers 
185. 

[0076] The example is implemented by a transaction 
oriented packet data communication system. The sys- 
tem comprises a media access control layer controller 
190 for determining a data backlog in a media access 
control layer buffer (TXBO and TXB1 ) and a media ac- 
cess control layer transmitter 1 66 for transmitting a BE- 
GIN PDU containing a flag (transaction size indicator) 
to a receiver 1 67. The system also includes a means for 
initiating (such as MCL 190 or management entity 170) 
a media access control layer transaction in response to 
the transmitting of the BEGIN PDU. 
[0077] While the specification in this invention is de- 
scribed in relation to certain implementations or embod- 
iments, many details are set forth for the purpose of il- 
lustration. Thus, the foregoing merely illustrates the 
principles of the invention. For example, this invention 
may have other specific forms. The described arrange- 
ment are illustrative and not restrictive. To those skilled 
in the art, the invention is susceptible to additional im- 
plementations or embodiments and certain of the details 
described in this application can be varied considerably 
without departing from the basic principles of the inven- 
tion. 



CONTINUE protocol data unit. 
2. The method of claim 1 , wherein the data blocks are 



Claims 

1. A method of implementing a radio link protocol com- 
pletion process for a transaction oriented packet da- 
ta communication system (105), the method com- 
prising the steps of: 

determining a data backlog with a media ac- 
cess control layer controller (190); 
transmitting to a receiver (135), a BEGIN pro- 
tocol data unit containing a flag; and 
initiating a media access control layer transac- 
tion in response to the transmitting of the BE- 
GIN protocol data unit, characterised In that 
the media access control layer controller (190) 
receives an indication at the data backlog from 
a network layer; 

the flag comprises a transaction size indicator; 
the media access control layer transaction is 
composed of a number of data blocks, and the 
media access control layer transaction has a 
beginning and an end; 

the data blocks are included in a CONTINUE 
protocol data unit (315); 
the number of data blocks is less than a system 
broadcast parameter; 

the BEGIN protocol data unit contains a trans- 
action size field that defines the number of data 
blocks (305); and 

an END control block is transmitted (320) with 
other data blocks as part of the 



3. The method as claimed in claim 1 , wherein the data 
blocks are retransmitted data blocks. 

4. The method of claim 1 , wherein the media access 
control layer controller (1 90) is committed to the end 
of the media access control layer transaction. 

5. The method of any of claims 2, 3 or 4, wherein ter- 
mination of the media access control layer transac- 
tion occurs when the transaction size field has a val- 
ue equal to zero. 

6. The method of any of claims 2 to 5, wherein the 
transaction size field values of 1 , 2 through 2 N -2 in- 
dicates that the media access control layer transac- 
tion has a number of data blocks equal to the value 
of the transaction size field value. 

7. The method of claim 1 , including transmitting the 
END control block by the media access control layer 
controller (190) when the number of data blocks in 
a transmit buffer is less than the value of the system 
broadcast parameter. 

so 8. The method of claim 12, wherein a last valid se- 
quence number is provided for the media access 
control layertransaction with the END control block. 

9. The method of claim 8, further including the step of 
35 recovering all of a plurality of data sequence num- 
bers up to and including the last valid sequence 
number. 

1 0. The method of claim 7, further including the step of 
40 initiating anothertransaction when new data blocks 

are received at the transmit buffer. 

1 1 . The method of claim 1 , wherein the BEGIN protocol 
data unit contains a proposed mode of operation for 

4s the media access control layer transaction. 

12. The method of claim 1 , wherein the mode of oper- 
ation is fixed coding. 

so 13. The method of any of claims 1 , 11 or 12, wherein 
the END control blocks have the same size as the 
fixed coding mode data blocks. 

14. The method of any of claims 1 or 11 to 13, wherein 
55 the data blocks start with an escape sequence as 

specified in RFC 1662. 

15. The method of any of claims 1 or 11 to 14, wherein 
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the END block is identified by at least one of a plu- 
rality of parity and control header. 

16. The method of claim 3, further including the ac- 
knowledging of the END control block using an END s 
block, received indicator. 

17. The method of claim 3 or 16, wherein the indicator 
is located in an ARC status protocol data unit. 

to 

18. The method of claim 3, 16 or 17, including sched- 
uling the END control block for retransmission. 

19. The method of claim 3, 16, 17 or 18, wherein the 
mode of operation is incremental redundancy ts 
mode. 

20. The method of claim 3, 16, 17, 18 or 19, wherein 
the END block is identified by at least one of a plu- 
rality of parity and control header. 20 

21. The method of claim 6,22,23,24,25 or 26, wherein 
the END control block is transmitted along with par- 
ity blocks as part of the CONTINUE protocol data 
unit. 25 

22. The method of claim 3 or 16 to 21, Including ac- 
knowledging the END control block using an END 
block received indicator. 

30 

23. The method of claim 3 or 16 to 22, wherein the in- 
dicator is located in an ARQ status protocol data 
unit. 

24. The method of claim 3 or 1 6 to 23, including sched- 35 
uling the END control block for retransmission. 

25. A transaction oriented packet data communication 
system comprising: 

40 

a media access control layer transmitter for 
transmitting a BEGIN protocol data unit con- 
taining a flag to a receiver; and 
means for initiating a media access control lay- 
ertransaction in response to the transmitting of ^ 
the BEGIN protocol data unit, characterized 
by: 

a media access control layer controller for 
determining a data backlog in a media ac- so 
cess control layer buffer, the flag compris- 
ing a transaction size indicator; wherein 
the number of data blocks is less than a 
system broadcast parameter; 
the BEGIN protocol data unit contains a 55 
transaction size field that defines the 
number of data blocks (305); 
the data blocks are included in a CONTIN- 



UE protocol data unit (325); and 
an END control block is transmitted with 
other data blocks as part of a CONTINUE 
protocol data unit (320). 

26. The system of claim 25, wherein the media access 
control layer transaction is composed of a number 
of data blocks, and the media access control layer 
transaction has a beginning and an end. 

27. The system of claim 25, wherein the data blocks are 
induded in a CONTINUE protocol data unit. 

28. The system as claimed in claim 25 or 27, wherein 
the data blocks are new data blocks. 

29. The system as claimed in claim 26, 27 or 28, where- 
in the data blocks are retransmitted data blocks. 

30. The system of claim 25, wherein the media access 
control layercontroller (1 90) is committed to the end 
of the media access control layer transaction. 

31 . The system of any of claims 27 to 30 wherein the 
system is adapted to terminate the media access 
control layer transaction when the transaction size 
field has a value equal to zero. 

32. The system as claimed in any of claims 27 to 31 , 
wherein the transaction size field values of 1,2 
through 2 N -2 indicates that the media access con- 
trol layer transaction has a number of data blocks 
equal to the value of the transaction size field value. 

33. The system of claim 25, wherein means are provid- 
ed for transmitting an 

END control block by the media access con- 
trol layer controller (1 90) when the number of data 
blocks in a transmit buffer is less than the value of 
the system broadcast parameter. 

34. The system of claim 33, wherein a last valid se- 
quence number is provided for the media access 
control layer transaction within the END control 
block. 

35. The system of claim 33 or 34, including the recovery 
of all of a plurality of data sequence numbers up to 
and including the last valid sequence number. 

36. The system of claim 25, wherein the system is 
adapted to recover all of a plurality of data sequence 
numbers up to and including the last valid sequence 
number. 

37. The system of claim 25 or 36, wherein the system 
is adapted to initiate another transaction when new 
data blocks are received at the transmit buffer. 
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38. The system of claim 25, wherein the BEGIN proto- 
col data unit contains a proposed mode of operation 
for the media access control layer transaction. 

39. The system of claim 25 or 38, wherein the mode of 
operation is fixed coding. 



40. The system of claim 25, 38 or 39, wherein the END 
control blocks have the same size as the fixed cod- 
ing mode data blocks. 



transaktionsorientiert.es Paketdatenkommunikati- 
onssystem (105), mit den folgenden Schritten: 

Bestimmen eines Dateniiberhangs mit einer 
Steuerung (190) der Medienzugriffssteuer- 
schicht; 

Senden einer BEGIN-Protokolldateneinheit, 
die ein Flag enthalt, zu einem Empfanger (1 35); 
und 



41. The system of claim 25, 38, 39 or 40, wherein the 
data blocks start with an escape sequence as spec- 
ified in RFC 1662. 

42. The system of claim 25, 38, 39, 40 or 41 , wherein 
the END block is identified by at least one of a plu- 
rality of parity and control header. 

43. The system of claim 25, wherein the system is 20 
adapted to acknowledge the END control block us- 
ing an END block received indicator. 

44. The system of claim 25 or 43, wherein the indicator 

is located in an ARQ status protocol data unit. 2s 

45. The system of claim 25, 43 or 44, wherein the sys- 
tem Is adapted to schedule the END control block 
for retransmission. 

30 

46. The system of claim 25, 43, 44 or 45, wherein the 
mode of operation Is Incremental redundancy 



47. The system of claim 25, 43, 44, 45 or 46, wherein 
the END block is identified by at least one of a plu- 
rality of parity and control header. 

48. The system of claim 25, 43, 44, 45, 46 or 47, where- 
in the system is adapted to transmit the END control 
block along with other data or parity blocks as part 
of the CONTINUE protocol data unit. 



Einleiten einer Transaktion der Medienzugriffs- 
steuerschicht als Reaktion auf das Senden der 
BEGIN-Protokolldateneinheit, dadurch ge- 
kennzeichnet, daB 

die Steuerung (190) der Medienzugriffssteuer- 
schicht eine Anzeige an dem Dateniiberhang 
aus einer Netzwerkschicht empfangt; 

das Flag einen TransaktionsgroBenanzeiger 



die Transaktion der Medienzugriffssteuer- 
schichtaus einer Anzahl von Datenblocken be- 
steht und die Transaktion der Medienzugriffs- 
steuerschicht einen Anfang und ein Ende auf- 
weist; 

die Datenblocke in einer CONTINUE-Protokoll- 
dateneinheit (315) enthalten sind; 

die Anzahl von Datenblocken kleiner als ein Sy- 
stemrundsendeparameter ist; 

die BEGIN-Protokolldateneinheit ein Transak- 
tionsgroBenfeld enthalt, das die Anzahl von Da- 
tenblocken (305) definiert; und 

als Teil der CONTINUE-Protokolldateneinheit 
ein END-Steuerblock mit anderen Datenblok- 
ken gesendet (320) wird. 



49. The system of claim 25, 43, 44, 45, 46, 47 or 48, 2. Verfahren nach Anspruch 1 , wobei die Datenblocke 
wherein the system is adapted to acknowledge the 45 ne ue Datenblocke sind. 



END control block using an END block received in- 



50. The system as claimed in claim 25, 43, 44, 45, 46, 
47, 48 or 49, wherein the indicator is located in an 
ARQ status protocol data unit, and/or scheduling 
the END control block for retransmission. 



Patentanspriiche 



1 . Verfahren zur Implementierung eines AbschluBpro- 
zesses eines Funkverbindungsprotokolls fur ein 



Verfahren nach Anspruch 1 , wobei die Datenblocke 
neu gesendete Datenblocke sind. 

Verfahren nach Anspruch 1 , wobei die Steuerung 
(1 90) der Medienzugriffssteuerschicht auf das En- 
de der Transaktion der Medienzugriffssteuerschicht 
festgelegt ist. 

55 5. Verfahren nach einem der Anspriiche 2, 3 Oder 4, 
wobei der SchluB der Transaktion der Medienzu- 
griffssteuerschicht auftritt, wenn das Transaktions- 
groBenfeld einen Wert von null aufweist. 
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6. Verfahren nach einem der Anspriiche 2 bis 5, wobei 
die TransaktionsgroBenfeldwerte 1, 2 bis 2 N -2 an- 
zeigen, daB die Transaktion der Medienzugriffs- 
steuerschicht eine Anzahl von Datenblocken auf- 
weist, die gleich dem Wert des Transaktionsgro- 
Benfeldwerts ist. 

7. Verfahren nach Anspruch 1 , bei dem der END-Steu- 
erblock durch die Steuerung (190) der Medienzu- 
griffssteuerschicht gesendet wird, wenn die Anzahl 
von Datenblocken in einem Sendepuffer kleinerals 
der Wert des Systemrundsendeparameters ist. 

8. Verfahren nach Anspruch 1 2, wobei eine letzte gul- 
tige Sequenznummerfiir die Transaktion der Medi- 
enzugriffssteuerschicht mit dem END-Steuerblock 
bereitgestellt wird. 

9. Verfahren nach Anspruch 8, bei dem weiterhin alle 
von mehreren Datensequenznummern bis zu ein- 
schlieBlich der letzten giiltigen Sequenznummer 
wiederhergestellt werden. 

10. Verfahren nach Anspruch 7, bei dem femer eine 
weitere Transaktion eingeleitet wird, wenn neue 
Datenblocke in dem Sendepuffer empfangen wer- 
den. 

11. Verfahren nach Anspruch 1 , wobei die BEGIN-Pro- 
tokolldateneinheit eine vorgeschlagene Betriebsart 
fur die Transaktion der Medienzugriffssteuerschicht 
enthalt. 

12. Verfahren nach Anspruch 1, wobei die Betriebsart 
Festcodierung ist. 

13. Verfahren nach einem der Anspriiche 1,11 oder12, 
wobei die END-Steuerblocke dieselbe GroBe wie 
die Datenblocke der Festcodierungsbetriebsart 
aufweisen. 

14. Verfahren nach einem der Anspriiche 1 oder 11 bis 

13, wobei die Datenblocke mit einer in RFC 1662 
spezifizierten Escape-Sequenz beginnen. 

15. Verfahren nach einem der Anspriiche 1 oder 11 bis 

14, wobei der END-Block durch mindestens einen 
von mehreren Paritats- oder Steuerkopfteilen iden- 
tifiziertwird. 

16. Verfahren nach Anspruch 3, bei dem weiterhin der 
END-Steuerblock durch Verwendung eines 
END-Block-empfangen-Anzeigers bestatigt wird. 

17. Verfahren nach Anspruch 3 oder 1 6, wobei sich der 
Anzeiger in einer ARQ-Statusprotokolldateneinheit 
befindet. 
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18. Verfahren nach Anspruch 3, 16 oder 17, bei dem 
weiterhin der END-Steuerblock fur ein Neusenden 
eingeplant wird. 

s 19. Verfahren nach Anspruch 3, 1 6, 1 7 oder 1 8, wobei 
die Betriebsart der Inkremental-Redundanz-Modus 
ist. 

20. Verfahren nach Anspruch 3, 1 6, 1 7, 1 8 oder 1 9, wo- 
10 bei der END-Block durch mindestens einen von 

mehreren Paritats- oder Steuerkopfteilen identifi- 
ziertwird. 

21. Verfahren nach Anspruch 6, 22, 23, 24, 25 oder 26, 
15 wobei der END-Steuerblock zusammen mit Pari- 

tatsblocken alsTeil derCONTINUE-Protokolldaten- 
einheit gesendet wird. 

22. Verfahren nach Anspruch 3 oder 1 6 bis 21 , bei dem 
20 der END-Steuerblock durch Verwendung eines 

END-Block-empfangen-Anzeigers bestatigt wird. 

23. Verfahren nach Anspruch 3 oder 1 6 bis 22, wobei 
sich der Anzeiger in einer ARQ-Statusprotokollda- 

25 teneinheit befindet. 

24. Verfahren nach Anspruch 3 oder 1 6 bis 23, bei dem 
der END-Steuerblockf iir ein Neusenden eingeplant 
wird. 

30 

25. Transaktionsorientiert.es Paketdatenkommunikati- 
onssystem, umfassend: 

einen Sender der Medienzugriffssteuerschicht 
35 zum Senden einer BEGIN-Protokolldatenein- 

heit, die ein Flag enthalt, zu einem Empfanger; 
und 

ein Mittel zum Einleiten einer Transaktion der 
40 Medienzugriffssteuerschicht als Reaktion auf 

das Senden der BEGIN-Protokolldateneinheit, 
gekennzeichnet durch: 

eine Steuerung der Medienzugriffssteuer- 
45 schicht zur Bestimmung eines Dateniiber- 

hangs in einem Puffer der Medienzugriffs- 
steuerschicht, wobei das Flag einen Trans- 
aktionsgroBenanzeiger umfaBt; wobei 

50 die Anzahl von Datenblocken kleiner ais 

ein Systemrundsendeparameter ist; 

die BEGIN-Protokolldateneinheit ein 
TransaktionsgroBenfeld enthalt, das die 
55 Anzahl von Datenblocken (305) definiert; 

die Datenblocke in einerCONTI NUE-Proto- 
kolldateneinheit (325) enthalten sind; und 
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ein END-Steuerblock mit anderen Daten- 
blocken als Teil einer CONTINUE-Proto- 
kolldateneinheit (320) gesendet wird. 

26. System nach Anspruch 25, wobei die Transaktion 
der Medienzugriffssteuerschicht aus einer Anzahl 
von Datenblocken besteht und die Transaktion der 
Medienzugriffssteuerschicht einen Anfang und ein 
Ende aufweist. 

27. System nach Anspruch 25, wobei die Datenblocke 
in einer CONTINUE-Protokolldateneinheit enthal- 
ten sind. 

28. System nach Anspruch 25 Oder 27, wobei die Da- 
tenblocke neue Datenblocke sind. 

29. System nach Anspruch 26, 27 Oder 28, wobei die 
Datenblocke neu gesendete Datenblocke sind. 

30. System nach Anspruch 25, wobei die Steuerung 
(190) der Medienzugriffssteuerschicht auf das En- 
de der Transaktion der Medienzugriffssteuerschicht 
festgelegt ist. 

31 . System nach einem der Anspruche 27 bis 30, wobei 
das System so ausgelegt ist, daB es die Transaktion 
der Medienzugriffssteuerschicht schlieBt, wenn das 
TransaktionsgroBenfeld einen Wert von null auf- 
weist. 

32. System nach einem der Anspruche 27 bis 31 , wobei 
die TransaktionsgroBenfeldwerte 1, 2 bis 2 N -2 an- 
zeigen, daB die Transaktion der Medienzugriffs- 
steuerschicht eine Anzahl von Datenblocken auf- 
weist, die gleich dem Wert des Transaktionsgro- 
Benfeidwerts 1st. 

33. System nach Anspruch 25, wobei ein Mittel vorge- 
sehen ist, das den END-Steuerblock durch die 
Steuerung (190) der Medienzugriffssteuerschicht 
sendet, wenn die Anzahl von Datenblocken in ei- 
nem Sendepuffer kleiner als der Wert des System- 
rundsendeparameters ist. 

34. System nach Anspruch 33, wobei eine letzte gultige 
Sequenznummerfur die Transaktion der Medienzu- 
griffssteuerschicht innerhalb des END-Steuer- 
blocks bereitgestellt wird. 

35. System nach Anspruch 33 Oder 34, einschlieBlich 
der Wiederherstellung allervon mehreren Datense- 
quenznummern bis zu einschlieBlich der letzten 
gultigen Sequenznummer. 

36. System nach Anspruch 25, wobei das System so 
ausgelegt ist, daB es Datensequenznummern bis 
zu einschlieBlich der letzten gultigen Sequenznum- 



30 

mer wiederherstellt. 

37. System nach Anspruch 25 Oder 36, wobei das Sy- 
stem so ausgelegt ist, daB es eine weitere Trans- 

5 aktion einleitet, wenn neue Datenblocke in dem 
Sendepuffer empfangen werden. 

38. System nach Anspruch 25, wobei die BEGIN-Proto- 
kolldateneinheit eine vorgeschlagene Betriebsart 

io fur die Transaktion der Medienzugriffssteuerschicht 
enthalt. 

39. System nach Anspruch 25 Oder 38, wobei die Be- 
triebsart Festcodierung ist. 

40. System nach Anspruch 25, 38 oder 39, wobei die 
END-Steuerblocke dieselbe GroBe wie die Daten- 
blocke der Festcodierungsbetriebsart aufweisen. 

20 41. System nach Anspruch 25, 38, 39 oder 40, wobei 
die Datenblocke mit einer in RFC 1662 spezifizier- 
ten Escape-Sequenz beginnen. 

42. System nach Anspruch 25, 38, 39, 40 oder 41 , wo- 
25 bei der END-Block durch mindestens einen von 

mehreren Paritats- oder Steuerkopfteilen identifi- 
ziert wird. 

43. System nach Anspruch 25, wobei das System so 
30 ausgelegt ist, daB es den END-Steuerblock durch 

Verwendung eines END-Block-empfangen-Anzei- 
gers bestatigt. 

44. System nach Anspruch 25 oder 43, wobei sich der 
35 Anzeiger in einer ARQ-Statusprotokolldateneinheit 

befindet. 

45. System nach Anspruch 25, 43 oder 44, wobei das 
System so ausgelegt ist, daB es den END-Steuer- 

40 block fur ein Neusenden einplant. 

46. System nach Anspruch 25, 43, 44 oder 45, wobei 
die Betriebsart der Inkremental-Redundanz-Modus 
ist. 

45 

47. System nach Anspruch 25, 43, 44, 45 oder 46, wo- 
bei der END-Block durch mindestens einen von 
mehreren Paritats- oder Steuerkopfteilen identifi- 
ziert wird. 

50 

48. System nach Anspruch 25, 43, 44, 45, 46 oder 47, 
wobei das System so ausgelegt ist, daB es den 
END-Steuerblock zusammen mit anderen Daten- 
oder Paritatsblocken als Teil der CONTINUE-Proto- 

55 kolldateneinheit sendet. 

49. System nach Anspruch 25, 43, 44, 45, 46, 47 oder 
48, wobei das System so ausgelegt ist, daB es den 



EP 0 959 589 B1 



16 



^imad 02\firm data\IP\Foleypat\PatentDocument s\EP 0009 59589.cpcl 



..Page 17 of 53 



END-Steuerblock durch Verwendung eines 
END-Block-empfangen-Anzeigers bestatigt. 

50. System nach Anspruch 25, 43, 44, 45, 46, 47, 48 
oder 49, wobei sich der Anzeiger in einer ARQ-Sta- 5 
tusprotokolldateneinheit befindet und/oder der 
END-Steuerblock fur ein Neusenden eingeplant 
wird. 

10 

Revendications 

1 . Procede de mise en oeuvre d'un processus d'eta- 
blissement de protocole de liaison radio pour un 
systeme de communication de donnees par pa- is 
quets oriente transactions (105), le procede com- 
prenant les etapes de : 

determination d'un arriere de donnees avec un 
controleur de couche de controle d'acces aux 20 
supports (190) ; 

transmission a un recepteur (135), d'une unite 
de donnees de protocole de COMMENCE- 
MENT contenant un drapeau ; et 
lancement d'une transaction de couche decon- 25 
trole d'acces aux supports en reponse a la 
transmission de I'unite de donnees de protoco- 
le de COMMENCEMENT, caracterlse en ce 
que: 

30 

le contrSleur de couche de controle d'ac- 
ces aux supports (1 90) regoit une indica- 
tion au niveau de I'amere de donnees a 
partir d'une couche de reseau ; 
le drapeau comprend un indicateur detaille 35 
de transaction ; 

la transaction de couche de controle d'ac- 
ces aux supports est composee d'un cer- 
tain nombre de blocs de donnees, et la 
transaction de couche de controle d'acces *o 
aux supports a un debut et une fin ; 
les blocs de donnees sont inclus dans une 
unite de donnees de protocole de CONTI- 
NUATION (315) ; 

le nombre de blocs de donnees est infe- « 
rieur a un parametre de diffusion de 
systeme ; 

I'unite de donnees de protocole de COM- 
MENCEMENT contient un champ de taille 
de transaction qui definit le nombre de so 
blocs de donnees (305) ; et 
un bloc de commande de FIN esttransmis 
(320) avec d'autres blocs de donnees dans 
le cadre de I'unite de donnees de protocole 
de CONTINUATION. 55 

2. Procede selon la revendication 1 , dans lequel les 
blocs de donnees sont de nouveaux blocs de don- 
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nees, 

3. Procede selon la revendication 1 , dans lequel les 
blocs de donnees sont des blocs de donnees re- 
transmis. 

4. Procede selon la revendication 1, dans lequel le 
contr&leur de couche de contr6le d'acces aux sup- 
ports (1 90) est engage jusqu'a la fin de la transac- 
tion de couche de controle d'acces aux supports. 

5. Procede selon la revendication 2, 3 ou 4, dans le- 
quel il est mis fin a la transaction de couche de con- 
trole d'acces aux supports quand le champ de taille 
de transaction a une valeur egale a zero. 

6. Procedeselon Tune quelconque des revendications 
2 a 5, dans lequel les valeurs de champ de taille de 
transaction de 1 , 2 a 2 N -2 indiquent que la transac- 
tion de couche de controle d'acces aux supports a 
un nombre de blocs de donnees egal a la valeur du 
champ de taille de transaction. 

7. Procede selon la revendication 1, comportant la 
transmission du bloc de commande de FIN par le 
controleur de couche de controle d'acces aux sup- 
ports (190) quand le nombre de blocs de donnees 
dans un tampon de transmission est inferieur a la 
valeur du param&tre de diffusion de systeme. 

8. Procede selon la revendication 1 2, dans lequel un 
num6ro de derniere sequence valable est fourni 
pour la transaction de couche de contr6le d'acces 
aux supports avec le bloc de commande de FIN. 

9. Procede selon la revendication 8, comportant en 
outre I'etape de recuperation de tous les numeros 
d'une pluralite de numeros de sequences de don- 
nees jusqu'au numero de derniere sequence vala- 
ble inclus. 

10. Procede selon la revendication 7, comportant en 
outre I'etape de lancement d'une autre transaction 
quand de nouveaux blocs de donnees sont recus 
au niveau du tampon de transmission. 

11. Procedeselon la revendication 1 , dans lequel I'unite 
de donnees de protocole de COMMENCEMENT 
contient un mode de fonctionnement propose pour 
la transaction de couche de controle d'acces aux 
supports. 

12. Procede selon la revendication 1, dans lequel le 
mode de fonctionnement est un codage fixe. 

13. Procedeselon I'une quelconquedes revendications 
1 , 1 1 ou 1 2, dans lequel les blocs de commande de 
FIN ont la meme taille que les blocs de donnees de 
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mode de codage fixe. 

14. Procedeselon I'unequelconquedes revendications 
1 ou 11 ou 13, dans lequel les blocs de donnees 
commencent par une sequence d'echappement tel- 
le specif iee dans le RFC 1662. 

15. Procedeselon I'unequelconquedes revendications 
1 ou 1 1 ou 1 4, dans lequel le bloc de Fl N est identif ie 
par au moins un d'une plurality d'entetes de parite 
et de commande. 

16. Proced6 selon la revendication 3, comportant en 
outre I'accuse de reception du bloc de commande 
de FIN en utilisant un indicateurdeblocde FIN recu. 



ou 16, dans lequel 
unite de donnees de 



17. Precede selon la 

I'indicateur est situe dans 
protocole d'6tat ARQ. 



18. Precede selon la revendication 3, 16 ou 17, com- 
portant un ordonnancement du bloc de commande 
de FIN pour la retransmission. 

19. Precede selon la revendication 3, 16, 17 ou 18, 
dans lequel le mode de fonctionnement est un mo- 
de de redondance incrementielle. 

20. Precede selon la revendication 3, 1 6, 1 7, 1 8 ou 1 9, 
dans lequel le blocde FIN est identifie parau moins 
un d'une pluralite d'en-tetes de parite et de com- 



21. Precede selon la revendication 6, 22, 23, 24, 25 ou 
26, dans lequel le bloc de commande de FIN est 
transmis ainsi que des blocs de parite dans le cadre 
de I'unite de donnees de protocole de CONTINUA- 
TION. 

22. Precede selon la revendication 3 ou 16 a 21 , com- 
portant un accuse de reception du bloc de comman- 
de de FIN en utilisant un indicateurde bloc de FIN 
recu. 

23. Precede selon la revendication 3 ou 1 6 a 22, dans 
lequel I'indicateur est situe dans une unite de don- 
nees de protocole d'etat ARQ. 

24. Precede selon la revendication 3 ou 16 a 23, com- 
portant I'ordonnancement du bloc de commande de 
FIN pour la retransmission. 

25. Systeme de communication de donnees par pa- 
quets oriente transactions comprenant : 

un emetteurde couche de controle d'acces aux 
supports pour emettre une unite de donnees de 
protocole de COMMENCEMENT contenant un 



drapeau a un recepteur ; et 

un moyen pour lancer une transaction de cou- 

che de contr8le d'acces aux supports en repon- 

se a la transmission de I'unite de donnees de 

protocole de COMMENCEMENT, caracterise 

par: 

un contr6leur de couche de contr6le d'ac- 
ces aux supports pour determiner un arrie- 
re de donnees dans un tampon de couche 
de contrdle d'acces aux supports, le dra- 
peau comprenant un indicateur de taille de 
transaction ; dans lequel 
le nombre de blocs de donnees est infe- 
rieur a un parametre de diffusion de 



I'unite de donn6es de protocole de COM- 
MENCEMENT contient un champ de taille 
de transaction qui definit le nombre de 
20 blocs de donnees (305) ; 

les blocs de donnees sont inclus dans une 
unite de donnees de protocole de CONTI- 
NUATION (325) ; et 

un bloc de commande de FIN est transmis 
2s avec d'autres blocs de donnees dans le ca- 

dre d'une unite de donnees de protocole 
de CONTINUATION (320). 

26. Systeme selon la revendication 25, dans lequel la 
30 transaction de couche de contrdle d'acces aux sup- 
ports est composee d'un certain nombre de blocs 
de donn6es, et la transaction de couche de contr6le 
d'acces aux supports a un debut et une fin. 

35 27. Systeme selon la revendication 25, dans lequel les 
blocs de donnees sont inclus dans une unite de 
donnees de protocole de CONTINUATION. 

28. Systeme selon la revendication 25 ou 27, dans le- 
40 quel les blocs de donnees sont de nouveaux blocs 

de donnees. 

29. Systeme selon la revendication 26, 27 ou 28, dans 
lequel les blocs de donnees sont des blocs de don- 

45 nees retransmis. 

30. Systeme selon la revendication 25, dans lequel le 
controleur de couche de controle d'acces aux sup- 
ports (1 90) est engage jusqu'a la fin de la transac- 

so tion de couche de controle d'acces aux supports. 

31. Systeme selon I'une quelconque des revendica- 
tions 27 a 30, dans lequel le systeme est adapte 
pour mettre fin a la transaction de couche de con- 

55 trole d'acces aux supports quand le champ de taille 
de transaction a une valeur egale a zero. 

32. Systeme selon I'une quelconque des revendica- 
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tions 27 a 31 , dans lequel les valeurs de champ de 
taille de transaction de 1 , 2 a 2 N -2 indiquent que la 
transaction de couche de contrSle d'acces aux sup- 
ports a un nombre de blocs de donnees egal a la 
valeur du champ de taille de transaction. 5 

33. Systeme selon la revendication 25, dans lequel des 
moyens sont fournis pour emettre un bloc de com- 
mande de FIN par le controleur de couche de con- 
trole d'acces aux supports (190) quand le nombre <o 
de blocs de donnees dans un tampon de transmis- 
sion est inferieur a la valeur du parametre de diffu- 
sion de systeme. 

34. Systeme selon la revendication 33, dans lequel un « 
numero de derniere sequence valable est fourni 
pour la transaction de couche de controle d'acces 
aux supports dans le bloc de commande de FIN. 

35. Systeme selon la revendication 33 ou 34, compor- 20 
tant la recuperation detous les numeros d'une plu- 
ralite de numeros de sequences de donnees jus- 
qu'au numero de derniere sequence valable inclus. 

36. Systeme selon la revendication 25, dans lequel le 25 
systeme est adapte pour recuperer tous les nume- 
ros d'une pluralite de numeros de sequences de 
donnees jusqu'au numero de derniere sequence 
valable inclus. 

30 

37. Systeme selon la revendication 25 ou 36, dans le- 
quel le systeme est adapte pour lancer une autre 
transaction quand de nouveaux blocs de donnees 
sont recus au niveau du tampon de transmission. 

38. Systeme selon la revendication 25, dans lequel 
I'unite de donnees de protocole de COMMENCE- 
MENT contient un mode de fonctionnement propo- 
se pour la transaction de couche de controle d'ac- 
ces aux supports. 40 

39. Systeme selon la revendication 25 ou 38, dans le- 
quel le mode de fonctionnement est un codage fixe. 

40. Systeme selon la revendication 25, 38 ou 39, dans « 
lequel les blocs de commande de FIN ont la meme 
taille que les blocs de donnees de mode de codage 
fixe. 

41. Systeme selon la revendication 25, 38, 39 ou 40, so 
dans lequel les blocs de donnees commencent par 
une sequence d'echappement telle specifiee dans 

le RFC 1662. 

42. Systeme selon la revendication 25, 38, 39, 40 ou ss 
41, dans lequel le bloc de FIN est identifie par au 
moins un d'une pluralite d'en-tetes de parite et de 
commande. 



43. Systeme selon la revendication 25, dans lequel le 
systeme est adapte pour accuser reception du bloc 
de commande de FIN en utilisant un indicateur de 
bloc de FIN recu. 

44. Systeme selon la revendication 25 ou 43, dans le- 
quel I'indicateur est situe dans une unite de don- 
nees de protocole d'etat ARQ. 

45. Systeme selon la revendication 25, 43 ou 44, dans 
lequel le systeme est adapte pour ordonnancer le 
bloc de commande de FIN pour la retransmission. 

46. Systeme selon la revendication 25, 43, 44 ou 45, 
dans lequel le mode de fonctionnement est un mo- 
de de redondance incrementielle. 

47. Systeme selon la revendication 25, 43, 44, 45 ou 
46, dans lequel le bloc de FIN est identifie par au 
moins un d'une pluralite d'en-tetes de parite et de 
commande. 

48. Systeme selon la revendication 25, 43, 44, 45, 46 
ou 47, dans lequel le systeme est adapte pour 
emettre le bloc de commande de FIN ainsi que 
d'autres donnees ou blocs de parite dans le cadre 
de I'unite de donnees de protocole de CONTINUA- 
TION. 

49. Systeme selon la revendication 25, 43, 44, 45, 46, 
47 ou 48, dans lequel le systeme est adapte pour 
accuser reception du bloc de commande de FIN en 
utilisant un indicateur de bloc de FIN recu. 

50. Systeme selon la revendication 25, 43, 44, 45, 46, 
47, 48 ou 49, dans lequel I'indicateur est situe dans 
une unite de donnees de protocole d'etat ARQ, et/ 
ou ordonnancant le bloc de commande de FIN pour 
la retransmission. 
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FIG. 7C 
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FIG. 10 
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GENERATE END 1 
CONTROL BLOCK 1 




ADD SCCxT ENTRY 
FOR END BLOCK: 
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BLSCCxT = END; 
BULSCCxT = END_Tx; 
NS-SCCxT = NULL; 




DELETE ORIGINAL Tx TABLE 
ENTRY AT NSLTxT = NS_Tx 



ADD SCCxT ENTRY FOR 
CONTINUE DATA BLOCK: 




ADD SCCxT ENTRY 
FOR FILLER BLOCK: 
!D_SCCxT=SCCx; 
BLSCCxT = FILLER; 
BULSCCxT = fILLEILTx; 
NS_SCCxT = NULL: 
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TRANSMITTED IN MODE 1 
CONTINUE PDU; ENDJjlFIAG- 
MHCATES WHETHER POLLING 
OF TxB IS ALLOWED 
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ADD SCCxT ENTRY FOR 
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END CONTROL BLOCK IS TRANSMITTED 
INSTEAD OF FILLER BLOCK WHEN 
END_TX_FLAG IS SET 
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FLAG 
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ULMODULATION = MT 
FROM ARQ_STATUS_Rx 
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FOR BLOCKS NAKed VIA BIT MAP 
BUT ABSENT FROM THE Tx TABLE, 
IT IS POSSIBLE TO IMPLEMENT 
MANUFACTURER-SPECIFIC 
PROCEDURES TO RECOVER 



BF_Rx = BIT MAP FROM 
ARQ_STATUS_Rx 
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ARO_STATUS_Rx 
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data.con 
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AMLCURRENT = AMI 
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FROM ARQ_STATUS_Rx 
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FLAG WILL 
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TRANSACTION 
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A INITIALIZE TCTX A 
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TRANSMISSION 
CONTROL FLAGS 
END_Tx_FLAG = FALSE 
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FIG. 19B 
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